[00:01.570 --> 00:07.150]  Hey everyone, my name is Martin, thank you for having me. Today I will be talking about the
[00:07.150 --> 00:15.810]  seven phases of smart contract hacking. In this talk my idea is not to jump and dive into technical
[00:15.810 --> 00:21.610]  parts of what it means to hack smart contracts, but actually I want to give a little bit of
[00:21.610 --> 00:27.370]  perspective and try to talk about the bigger picture of what does it actually mean to hack
[00:27.370 --> 00:34.910]  smart contracts. So if you're a pentester, if you're a bug hunter, perhaps working in application
[00:34.910 --> 00:43.250]  security or other realms of information security, you can jump into the Ethereum ecosystem and start
[00:43.250 --> 00:49.690]  helping us secure the entire platform. So a little bit of background about myself, I'm Martin,
[00:50.370 --> 00:55.430]  I'm a security researcher at Open Zeppelin, one of the leading companies in smart contract audits
[00:55.430 --> 01:00.570]  in Ethereum. I'm a systems engineer, I'm doing a master's degree in cyber security and cyber
[01:00.570 --> 01:05.850]  defense at the University of Buenos Aires, and I used to work as a pentester mainly on application
[01:05.850 --> 01:13.250]  security, infrastructure, mobile applications, web applications at a big four. And then I jumped
[01:13.250 --> 01:18.670]  into being a security researcher here at Open Zeppelin. Well let's say again that you're a
[01:18.670 --> 01:25.350]  pentester, you might be a bug hunter, a white hat hacker, perhaps working in other realms of
[01:25.350 --> 01:31.610]  information security, but you're interested in blockchains and smart contracts, you have heard
[01:31.610 --> 01:38.650]  about them, because to be honest we have hit the headlines a couple of times. There has been many
[01:38.650 --> 01:48.530]  hacks in the latest months around smart contracts in Ethereum. So as you see, many hacks and in my
[01:48.530 --> 01:53.230]  opinion we need more and more security experts to jump into the field and to help us secure the
[01:53.230 --> 01:59.910]  entire ecosystem. So this talk is mainly aimed at you. And the question is if you can hack a
[01:59.910 --> 02:05.310]  smart contract, right? What knowledge do you have already that can help you out here
[02:05.310 --> 02:12.570]  in the smart contract world and that you can start applying today to start hacking smart contracts?
[02:12.570 --> 02:17.110]  And well the answer is yes, that you do have some knowledge, because you do know which are
[02:17.110 --> 02:22.670]  the seven phases, let's say, of a typical security engagement. And when I say seven,
[02:22.670 --> 02:27.630]  I don't mean to be strict with these phases that we will be talking about. It's just a way of
[02:27.630 --> 02:34.110]  organizing the talk, but perhaps when you do bug hunting, some phases you might skip them or you
[02:34.110 --> 02:40.790]  might do others, but the idea is to outline our work as security auditors or bug hunters or white
[02:40.790 --> 02:48.530]  hackers in these seven phases, so we can have a common language to talk about this.
[02:49.310 --> 02:55.290]  Well, these are the seven phases that I have, that we will be talking about. First,
[02:55.290 --> 03:00.090]  scoping, then reconnaissance, identification of vulnerabilities, exploiting these vulnerabilities
[03:00.090 --> 03:06.550]  that we have found. What does it actually mean to do post-exploitation in the smart contract world?
[03:06.550 --> 03:10.610]  And we'll be asking ourselves whether that's an actual thing or not.
[03:10.690 --> 03:16.750]  And then we'll be briefly covering reporting fixes and retests. So you might be already familiar with
[03:16.750 --> 03:22.090]  these phases. The idea of today is to see how these phases apply in the smart contract world
[03:22.630 --> 03:26.370]  and whether we can start drawing some parallels between these phases
[03:27.110 --> 03:35.050]  and the ones that you are used to applying. So let's get started. Let's talk about scoping.
[03:36.110 --> 03:41.270]  If you come from the, let's say, application security world or maybe doing pen testing for
[03:41.270 --> 03:47.570]  infrastructure exposed on the internet, you might be familiar with the fact that you have IP
[03:47.570 --> 03:55.530]  addresses, right? When you are scoping your work, you will be given IP addresses that will help you
[03:55.530 --> 04:03.210]  understand the systems that you are about to audit or to assess. In the Ethereum case,
[04:03.210 --> 04:07.910]  we also have addresses. In this case, we have Ethereum addresses. I know they are not the same.
[04:07.910 --> 04:12.930]  I know there are many differences between them, but the idea is to start drawing, as I said before,
[04:12.930 --> 04:24.370]  some parallels between the worlds. So we can think of these addresses as ways of allocating resources,
[04:24.370 --> 04:27.810]  let's say, in the first case on a network and in the other case on the blockchain.
[04:29.290 --> 04:34.590]  When you are working on smart contracts, you will not only have one Ethereum address, but you can
[04:34.590 --> 04:39.010]  have many Ethereum addresses that are related to each other. And you may not even have Ethereum
[04:39.010 --> 04:45.010]  addresses, but actually you can have domain names, right? As in the classic world, you have the DNS
[04:45.010 --> 04:51.770]  that will help you resolve from human readable names to actual IP addresses. In Ethereum, we
[04:51.770 --> 04:57.670]  have the Ethereum nice service, which will help you translate human readable domain names like
[04:57.670 --> 05:06.130]  johndoe.eth to Ethereum addresses, such as the one there. But sometimes, most times actually,
[05:06.130 --> 05:12.110]  you won't have... perhaps you won't have an Ethereum address or many addresses. You might
[05:12.610 --> 05:17.130]  only have Solidity source code. And Solidity is the smart contract language that we use
[05:17.130 --> 05:21.430]  nowadays. There might be others, but Solidity is the smart contract language
[05:21.430 --> 05:29.510]  that is high level and that can help you code smart contracts in an easy way, let's say. So
[05:31.090 --> 05:38.730]  you might be given a repository with these files or you can actually find that source
[05:38.730 --> 05:44.150]  code in Etherscan, which is the main explorer for the Ethereum blockchain. And at this point,
[05:44.910 --> 05:49.450]  engagement will become something like a white box engagement, right? You will have access to
[05:49.450 --> 05:55.070]  the source code, but there are ways, as we will see later, to actually deploy these contracts
[05:55.070 --> 06:01.650]  and to start poking around with them as a living program. So there are two ways, perhaps, of
[06:02.410 --> 06:10.290]  approaching the assessment. So if you want to go to Etherscan, you can find the verified source
[06:10.290 --> 06:15.810]  code there. This is, for instance, the source code for DAI, one of the main stable coins in
[06:15.810 --> 06:20.830]  the Ethereum ecosystem. And you can go to its address and retrieve the source code there.
[06:20.830 --> 06:28.730]  But if you don't have the code, you can actually decompile the EVM bytecode and try to
[06:29.990 --> 06:38.110]  read it in a nicer way using EVM, right? So this is a decompiler for Solidity code
[06:38.110 --> 06:47.550]  and will help you understand what's behind this sometimes difficult to parse EVM bytecode
[06:47.550 --> 06:54.270]  and will give you a more readable way to understand it. So again, you might have the
[06:54.270 --> 06:58.790]  source code, but if you don't and you only have an Ethereum address, you can use this decompiler
[06:58.790 --> 07:05.690]  that can help you out. Well, once we are done with this scoping phase, we move on to the second one,
[07:05.690 --> 07:11.590]  which is reconnaissance. In reconnaissance, we basically want to understand what's in there,
[07:11.590 --> 07:19.770]  right? So we might be given, as I said before, a list of files. And we are not only talking about
[07:19.770 --> 07:24.930]  one, two, three, but many, many and several files that you might be given. And sometimes the names
[07:24.930 --> 07:31.010]  of these files don't even make much sense at the beginning, right? So we see here like files
[07:31.010 --> 07:37.070]  named flap, flip, flop. And that is not so self-explanatory, to be honest.
[07:37.170 --> 07:43.830]  So we need to start looking deeper into the files and to actually understand what they are doing.
[07:43.830 --> 07:48.910]  But when we look deeper into the files, we will see Solidity code, right? This is what
[07:48.910 --> 07:55.530]  actual Solidity looks like. Just a brief example for those that are not familiar with it.
[07:55.530 --> 08:02.630]  It looks like another object-oriented language. At the beginning, the syntax is similar. As you
[08:02.630 --> 08:09.050]  go deeper and deeper into Solidity, you might start seeing several differences with other languages.
[08:09.050 --> 08:15.190]  But again, the first look of Solidity looks like another object-oriented language.
[08:16.130 --> 08:21.510]  But if you go to actual files, to actual Solidity files today being used in Ethereum,
[08:21.510 --> 08:28.110]  you will see that sometimes developers are not that clear with their intentions of the code,
[08:28.110 --> 08:33.190]  and you will see that functions have weird names, some variable names are not that clear,
[08:33.190 --> 08:38.670]  and you cannot make much sense out of the things that you are reading in the code, right? So
[08:38.670 --> 08:44.270]  it might be a bit disorganized or repetitive, or the function names might not be the best,
[08:44.270 --> 08:50.110]  as we see in these cases. But luckily, there are tools and there are things that we can start doing
[08:50.110 --> 08:55.850]  in this reconnaissance phase that can help us get more familiar with the code and understand
[08:55.850 --> 09:01.830]  what it's trying to do. So in this case, what we want is, we want to understand the architecture,
[09:01.830 --> 09:07.970]  the interactions between the contracts, we want to see where the contracts expose functions,
[09:07.970 --> 09:12.130]  because we need to use them as entry points for attacks, we need to see the inheritance
[09:12.130 --> 09:17.790]  chains of this contract, and many other things, right? But I want to make a special point on
[09:17.790 --> 09:26.430]  intention. We as, let's say, auditors or bug hunters looking at Ethereum smart contracts,
[09:26.430 --> 09:31.550]  we need to understand the intention of the code, right? Intention is not usually the same as
[09:32.110 --> 09:36.650]  implementation, so we need to find the differences between intention and implementation,
[09:36.650 --> 09:45.030]  and actually start digging bugs in that sense. So special attention to the intention of the code,
[09:45.030 --> 09:52.450]  not only what it's actually doing, but what it intends to do. For these three last points,
[09:52.450 --> 09:58.550]  for the roles of a system, the integration points, and intention, the work in reconnaissance becomes
[09:58.810 --> 10:05.490]  a bit of a manual work, and reading documentation, reading the code, reading pull requests, perhaps
[10:05.490 --> 10:11.670]  talking to developers, from those things we can start understanding these points, right? But for
[10:11.670 --> 10:17.450]  the others, there are tools that can actually help us in a really nice way, as we are about to see.
[10:17.590 --> 10:23.310]  So if you want to see some things about inheritance chains, for example, you can use
[10:23.310 --> 10:31.270]  EtherScan, we can use Surya, Slyther, which are tools that can help us print these kind
[10:31.270 --> 10:36.810]  of diagrams of inheritance, and can help us understand how do contracts relate to each other
[10:36.810 --> 10:44.470]  in a code base. Slyther, that is a static analyzer, can also help us see which are the
[10:44.470 --> 10:51.210]  exposed functions of a contract, so we can see whether it has many public functions, which are
[10:51.210 --> 10:57.730]  these public functions, to which contracts do they belong, and if there are private functions
[10:57.730 --> 11:04.750]  in those contracts related to these public functions. So Slyther can help us explore this.
[11:05.610 --> 11:11.510]  There are also IDE plugins, such as in Visual Studio Code you have the Solidity Auditor plugin,
[11:11.510 --> 11:17.590]  which is super useful, and as you see here in the GIF, it can help you track, for instance,
[11:17.590 --> 11:24.210]  function calls. Starting from a public function call, you can go all the way down to the private
[11:24.210 --> 11:30.790]  calls, and see whether in this way you can track different bugs in the code.
[11:31.410 --> 11:36.310]  And another thing that is super useful, that I at least myself find useful,
[11:36.310 --> 11:41.170]  are diagrams. So these diagrams are things that you can actually draw yourself,
[11:41.170 --> 11:48.430]  put together yourself, and can help you out really to find several bugs in the code. So
[11:48.430 --> 11:54.310]  give it a shot, try it out, please don't go so crazy on it, but again can help you
[11:54.310 --> 12:00.090]  understand the relationships between different contracts and functions and dynamics of the system.
[12:02.090 --> 12:08.530]  So that's about it with reconnaissance. We have seen tools, we have seen manual things that you
[12:08.530 --> 12:15.550]  can use, and now let's get on to one of the most interesting parts, I guess, which is
[12:15.550 --> 12:21.490]  vulnerability identification. So this is one of the main objectives of our assessment, is to
[12:21.490 --> 12:26.770]  actually find vulnerabilities in the code. And if you're a beginner with it, I wouldn't recommend
[12:26.770 --> 12:34.730]  you to start trying to hack smart contracts in crazy new ways. I would suggest that you start
[12:34.730 --> 12:41.730]  with the basics. So you might read the Mastering Ethereum book, you can read online databases of
[12:41.730 --> 12:48.510]  known attacks, we have the SWC registry which classifies vulnerabilities and with different
[12:48.510 --> 12:53.650]  test cases. Of course not all vulnerabilities, not all weaknesses in smart contracts, but the
[12:53.650 --> 13:00.210]  most common ones are there, and you can go ahead and read them and start learning which are the
[13:00.210 --> 13:08.390]  basics of smart contract security. But if you like learning as playing, like learning by doing,
[13:08.390 --> 13:15.250]  you can play the Ethernode by OpenZeppelin, which is a kind of a capture the flag challenge, a set of
[13:15.250 --> 13:21.030]  challenges actually, and it's super fun and can help you understand how to hack smart contracts
[13:21.030 --> 13:29.150]  and learn about security in that way. One thing that also always surfaces when we talk about
[13:29.150 --> 13:33.950]  vulnerability identification in smart contracts is this difference between automated and manual
[13:33.950 --> 13:38.910]  work, right? I think this also happens in, for instance, application security, where you
[13:38.910 --> 13:46.330]  might have scanners that can help you out identify vulnerabilities in an application,
[13:47.040 --> 13:55.150]  but also people or pen testers, hackers, tend to also do some manual work. So I guess it's always
[13:55.150 --> 14:02.010]  about complementing the automated and manual work. You shouldn't fully lean towards one or another,
[14:02.010 --> 14:09.490]  but doing both automated and manual work to find out these vulnerabilities.
[14:10.510 --> 14:16.530]  So in the automated realm, we find many tools that can help us out in Ethereum
[14:17.170 --> 14:21.770]  for smart contracts insolidity, or perhaps you don't even need for some of these tools,
[14:21.770 --> 14:26.570]  the source code, you can only have the EVM bytecode. We have Slyther, Manticore,
[14:26.570 --> 14:32.430]  Keyedna, Mithril, Veris, Solpacale, and many more. I won't dive deeper into this. The program
[14:32.430 --> 14:38.510]  analysis world is extremely interesting and it's a whole world on its own. The idea of this talk
[14:38.510 --> 14:46.090]  is just to briefly present them. And to also mention that, of course, the automated tools,
[14:46.090 --> 14:51.890]  while they are good, they might have bugs, right? They might not always work as expected,
[14:51.890 --> 14:57.350]  they might produce false positives, and they might not even find the most critical bugs.
[14:57.750 --> 15:03.330]  So last year, we ended up publishing a post when we found a critical vulnerability in the
[15:03.330 --> 15:10.490]  MakerDAO contracts. And we realized that many of the tools weren't capable of finding that type of
[15:10.490 --> 15:18.450]  bug. And the forum post became really interesting when the authors of these tools jumped in and
[15:18.450 --> 15:23.250]  started explaining the improvements that they were applying in the tools to actually find the bug.
[15:23.250 --> 15:29.710]  And I think that right now, many of these tools are already capable of finding this bug that we
[15:29.710 --> 15:37.170]  found at MakerDAO. So the automated tool world is always moving forward and coming up with new
[15:37.170 --> 15:42.770]  ways of finding vulnerabilities, and that's super cool. But also, we do manual work, right? In this
[15:42.770 --> 15:48.170]  case, we focus on the business logic and the intention of the code. And this actually means
[15:48.170 --> 15:56.690]  that, at least in my experience, most of the most critical bugs that I have found in smart contracts
[15:56.690 --> 16:04.510]  come actually from business logic and not from, let's say, solidity common patterns. So by
[16:04.510 --> 16:09.650]  understanding the business logic of the contracts, you can actually start highlighting these differences
[16:09.650 --> 16:15.030]  between implementation and intention and start coming up with different attack vectors to break
[16:15.030 --> 16:22.110]  the contract. Special care should be paid to sensitive functions. And when I say
[16:22.110 --> 16:29.050]  sensitive, I mean functions that may have convoluted and mixed logic, functions that,
[16:29.050 --> 16:35.710]  let's say, handle decimals, arise signatures, which are usually not so straightforward to do
[16:35.710 --> 16:42.770]  in solidity. So usually developers need to come up with different hacks to implement,
[16:42.770 --> 16:48.570]  let's say, handling decimals. So there might be bugs there. Dangerous math,
[16:50.050 --> 16:55.170]  functions making external calls to untrusted contracts is also something that we should be
[16:55.170 --> 17:02.110]  paying attention to. And uses of assembly or low-level calls in solidity is usually
[17:03.370 --> 17:10.090]  a good source of vulnerabilities that I have seen in my years doing smart contract audits.
[17:10.090 --> 17:15.070]  So again, some of these are really important things that we should be paying attention to
[17:15.070 --> 17:21.070]  when we are assessing smart contracts in a manual way. But there are more, right? So we can
[17:21.070 --> 17:25.610]  also pay attention to the interactions with external dependencies. And in this case,
[17:25.610 --> 17:31.490]  let's say, other protocols, price oracles, decentralized exchanges, are points of
[17:31.490 --> 17:38.910]  interaction that sometimes can trigger different dynamics, different functionalities or unexpected
[17:38.910 --> 17:48.810]  things in the system that we are trying to break. Another thing to pay attention to is the impact
[17:48.810 --> 17:56.210]  of these dynamics, of novel dynamics, extreme unexpected ones, that perhaps the developers
[17:56.210 --> 18:02.550]  didn't take into account when they were developing the system and we should be paying attention to.
[18:02.550 --> 18:08.610]  So for instance, flash loans have been the big new thing recently in DeFi and Ethereum.
[18:08.610 --> 18:15.590]  With the introduction of flash loans, we have found that many projects ended up having problems
[18:15.590 --> 18:20.750]  in their dynamics, in their incentives, just because flash loans were available to everyone
[18:20.750 --> 18:26.610]  in the ecosystem. Having a clogged network is also something to take into account when we are
[18:26.610 --> 18:32.630]  analyzing smart contracts. What happens if the network is highly congested and transactions
[18:32.630 --> 18:42.230]  cannot go through? What happens if the price of ETH goes down by half and how would this project
[18:42.230 --> 18:47.350]  that I'm analyzing would react to that? Another cool thing going on right now in Ethereum is
[18:47.350 --> 18:51.850]  front-running, back-running and transaction ordering. So there are lots of bots right now
[18:51.850 --> 18:58.510]  in mainnet playing with front-running and back-running and these are things, really interesting
[18:58.510 --> 19:03.090]  things, that we should also take into account if we are trying to find vulnerabilities. How would
[19:03.090 --> 19:11.400]  the project, the contract we are seeing, react to these kind of things? Well, once we have
[19:12.880 --> 19:19.380]  found vulnerabilities, it's time for us to exploit them. Another fun part of doing
[19:19.380 --> 19:25.680]  security research is actually exploit the things that we found. To do exploiting, what we want is
[19:25.680 --> 19:33.460]  first to have a reproducible attack vector and that means to have some way of sharing with
[19:33.460 --> 19:39.440]  the client, sharing with the bug bounty report that we are about to submit, that we have a reproducible
[19:39.440 --> 19:43.840]  attack vector and we are proving actually that there is a vulnerability and that can be exploited
[19:43.840 --> 19:50.560]  under a certain scenario. And we also need to understand the impact that actually
[19:50.560 --> 19:57.680]  exploiting this would have in the system. And for the impact, to be honest, we usually also need to
[19:57.680 --> 20:06.140]  see or to actually to understand how would the system work and how the system reacts to our
[20:06.140 --> 20:10.640]  exploit and what is the actual impact in the business logic of the system. So we need some
[20:11.200 --> 20:16.700]  knowledge, business logic related knowledge, to the system that we are assessing.
[20:18.460 --> 20:24.180]  To do exploiting, my recommendation is to also try your exploits in a local testing environment. You
[20:24.180 --> 20:30.180]  shouldn't do that at mainnet, of course. So you can first spin up a local node. You can do that with
[20:30.180 --> 20:37.800]  ganache or with geth. Geth allows you to have a development mode so your test will run faster.
[20:37.800 --> 20:41.920]  And with ganache, there is a cool feature that you can do is to actually fork mainnet.
[20:41.920 --> 20:51.800]  And so you can point ganache to a, let's say, a full node, fork mainnet into your local environment
[20:51.800 --> 20:57.960]  and actually run your exploits as if they were to be run on mainnet, but you will be like
[20:58.640 --> 21:04.520]  causing no damage to any project out there. To interact with nodes, you can use, if you are
[21:05.100 --> 21:11.180]  hacking on javascript, you can use web3js or ethers, but I think that web3 is also available
[21:11.180 --> 21:18.760]  for python. And if you are wanting to do bigger things that perhaps it would be too difficult to
[21:19.420 --> 21:25.160]  only do with web3js or with ethers, you can use biddler or truffle, which are kind of frameworks
[21:25.160 --> 21:34.120]  or task runners that can help you do more crazy and bigger things with your exploits.
[21:34.720 --> 21:39.120]  These are the ones that I personally use and the ones I recommend. But of course,
[21:39.120 --> 21:43.600]  there might be others out in the space that can help you out too. If you want to see some
[21:43.600 --> 21:48.860]  exploit examples actually using some of the tools that I just mentioned, we have published in the
[21:48.860 --> 21:57.020]  OpenSampling GitHub repository an exploit for the Uniswap vulnerability that was found by another
[21:57.020 --> 22:01.820]  auditing company, by Consensus Intelligence, last year, and that we ended up publishing
[22:03.240 --> 22:08.200]  a proof-of-concept exploit on how that vulnerability can be exploited for some kind
[22:08.200 --> 22:14.600]  of tokens in Uniswap pools. And the exploit is readily available there and is public and for you
[22:14.600 --> 22:21.040]  to see and run it in your local machines. Interestingly, this exploit was actually,
[22:21.610 --> 22:26.420]  I don't know if this particular exploit, but the vulnerability was later exploited in the wild in
[22:26.420 --> 22:34.720]  some real Uniswap pools. I have also published myself some exploits examples in my GitHub
[22:34.720 --> 22:41.120]  repository. And in February this year, for example, we also at OpenSampling published
[22:41.740 --> 22:46.540]  a way to backdoor non-c-safe wallets, one of the most popular wallets in the space,
[22:46.540 --> 22:53.020]  during deployment. And in this post, I'm leaving you the link there, in this post we are
[22:53.020 --> 23:01.780]  actually publishing the proof-of-concept exploit on how to backdoor non-c-safe wallets during deployment.
[23:02.700 --> 23:09.680]  But also we have the possibility to reproduce real exploits in Ethereum. So you can see here
[23:09.840 --> 23:18.600]  a transaction, an execution trace of a transaction that actually stole more than 24k USDC
[23:18.600 --> 23:25.880]  last week on a project in Ethereum. On mainnet this is real and the attack not only
[23:25.880 --> 23:33.080]  was made up of this single transaction but many transactions and caused a lot of fund losses
[23:33.820 --> 23:38.780]  in this project. So you can actually see these transactions because transactions are public in
[23:38.780 --> 23:44.900]  Ethereum. You can see the interactions between the contracts and you can even go ahead and
[23:44.900 --> 23:50.440]  reproduce these real exploits on your local environments. So that is something pretty cool.
[23:51.660 --> 23:58.180]  Well, moving on, after exploiting we can begin talking about post-exploitation, right? So
[23:59.180 --> 24:05.720]  the big question here that I've been asking myself when preparing this talk is if this is
[24:05.720 --> 24:11.400]  even a thing, right? So in the application security world perhaps you might be
[24:11.400 --> 24:19.920]  thinking of pivoting, opening a shell, moving to other systems, jumping around the network,
[24:19.920 --> 24:26.480]  but perhaps in the smart contract world that is not possible or it is not that easy to
[24:26.480 --> 24:32.840]  draw a parallel between the smart contract and other worlds. So again, we shouldn't think of
[24:32.840 --> 24:40.800]  having a shell here but perhaps we can start thinking about, when thinking about post-exploitation,
[24:40.800 --> 24:47.720]  we can try to extend or elevate access to the smart contracts. We can cause further
[24:47.720 --> 24:53.940]  consequences in our components or even in other protocols by going beyond the
[24:53.940 --> 24:58.980]  exploited system that we are assessing, right? So in that sense there might be some parallels between
[25:00.940 --> 25:09.580]  in this post-exploitation phase. So let's go to an example to better see what I mean by
[25:09.580 --> 25:17.200]  post-exploitation here. So let's see a compromised oracle case. In this case, let's imagine
[25:17.400 --> 25:21.980]  a platform that is selling collectibles, is selling these kitties and you pay ETH and it
[25:21.980 --> 25:28.040]  will give you away some kitties depending on how much ETH you have paid. But this platform actually
[25:28.040 --> 25:37.900]  uses the price in ETH of these kitties but uses a price oracle to fetch the price in ETH, right?
[25:37.900 --> 25:42.860]  The price oracle is basically another set of contracts where the price in ETH of these kitties
[25:42.860 --> 25:52.920]  is registered by someone. But in this case, if you can end up finding a vulnerability in the
[25:52.920 --> 25:58.160]  price oracle and you can compromise the price oracle, you can actually compromise the system
[25:58.160 --> 26:02.440]  that is relying on that oracle, right? Because you can set, for instance, the price in ETH of
[26:02.440 --> 26:07.520]  this collectible to zero, you can send a transaction to buy all kitties and you can steal away all
[26:07.520 --> 26:13.080]  kitties in this platform. And that is not also true for a single platform that relies on this
[26:13.080 --> 26:19.080]  oracle, but it's also true for all platforms that are actually relying on this price oracle. This is
[26:19.080 --> 26:24.100]  an actual problem that I think that we have nowadays in Ethereum. The more projects that
[26:24.100 --> 26:30.740]  are relying on a single oracle or just a small number of oracles, the greater the incentives,
[26:30.740 --> 26:36.600]  the economic incentives to attack a price oracle, to compromise it and to basically pound every
[26:36.600 --> 26:42.360]  single project depending on it. So this is basically what I mean with post exploitation.
[26:42.360 --> 26:48.420]  We can compromise an oracle and by doing that we can move on to other projects and execute attacks
[26:48.420 --> 27:00.650]  in them as well. Moving on, we have this last phases which is about reporting, doing fixes,
[27:00.650 --> 27:09.130]  retests and I believe that there are many similarities with other information security
[27:09.130 --> 27:15.950]  realms. So I don't think I should dive deeper into this. Of course we do reporting, of course
[27:15.950 --> 27:23.390]  we review the fixes for our clients, of course we do retests to make sure they haven't reintroduced
[27:23.390 --> 27:28.810]  the vulnerability and have actually fixed the things that we have reported. So we do all of
[27:28.810 --> 27:33.530]  that, that is basically the same. But one thing that we should be highlighting here is that in
[27:33.530 --> 27:41.770]  the Ethereum world most, if not all, but most security reports are public. That is something
[27:41.770 --> 27:46.390]  that you don't see in other worlds. That is something that, for instance, me working as a
[27:46.390 --> 27:53.570]  pen tester for banks in my previous job, I wouldn't have even imagined that I could at some point make
[27:53.570 --> 27:58.950]  public a report, right? But in the Ethereum world that is true, you can do that, of course agreeing
[27:58.950 --> 28:04.850]  that with the client, but I think everyone is encouraged to actually public their security
[28:04.850 --> 28:10.570]  reports because in that way we can all improve the ecosystem, we can all learn about the best
[28:10.570 --> 28:17.690]  security practices, which things might not be the best for some types of projects, and also to have
[28:17.690 --> 28:25.470]  perspectives of other security auditors in the space and learn from each other and
[28:26.090 --> 28:32.610]  make everything in the open and as transparent as possible. So we have public security reports and
[28:32.610 --> 28:38.950]  you can go to, for instance, our blog at OpenZeppelin and many other companies as well are publishing
[28:38.950 --> 28:44.210]  their reports and you can read them and learn tons about smart contract hacking and security
[28:44.210 --> 28:49.030]  and research just by reading those public security reports. So that is something that I
[28:49.030 --> 28:56.670]  wanted to highlight because I think it's super valuable in the space. Well, and to end this talk
[28:58.130 --> 29:04.430]  I wanted to leave you with a little surprise, right? I don't think today I have covered many
[29:04.430 --> 29:10.930]  things on the technical side just because I wanted to, as I told you at the beginning,
[29:10.930 --> 29:15.730]  I wanted to give you the bigger picture of what does it mean to hack smart contracts and how do
[29:15.730 --> 29:23.010]  we structure our engagements. But if you actually want to look at code and run some exploits and
[29:23.010 --> 29:31.130]  try to break smart contracts, I think you might find this super useful and entertaining. It's time
[29:31.130 --> 29:35.250]  for you to start hacking smart contracts so you can start applying all these learnings from these
[29:35.250 --> 29:40.590]  phases that I have been telling you about. You can go to my github repository, it's already public,
[29:40.590 --> 29:47.110]  and you can start hacking a set of smart contracts that is based on a governance system
[29:47.110 --> 29:53.770]  using flash loans and token snapshots, all things and features super popular nowadays in the FIFA
[29:53.770 --> 30:01.170]  space. And here you have an example on how that can be severely broken and you can be the one
[30:01.170 --> 30:08.270]  attacking it and breaking it. So please have fun with it and hope to get some feedback on that if
[30:08.270 --> 30:16.610]  you happen to play it. So thank you very much, you can contact me on telegram, on twitter,
[30:16.610 --> 30:23.070]  on github and all these platforms. You can find me as Tim Chavate and you can learn more about
[30:23.070 --> 30:28.810]  information security related to smart contracts in our forum, in our blog at Open Zeppelin.
[30:29.670 --> 30:36.090]  I'm happy to help you out with anything related to this and please
[30:36.990 --> 30:41.430]  ping me if you find this interesting. So thank you!
